home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970104-19970326 / 000265_news@columbia.edu _Mon Feb 17 06:06:00 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id GAA24842
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 17 Feb 1997 06:05:59 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id GAA13376
  7.     for kermit.misc@watsun; Mon, 17 Feb 1997 06:05:59 -0500 (EST)
  8. Newsgroups: comp.protocols.kermit.misc
  9. Path: news.columbia.edu!panix!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!news.maxwell.syr.edu!hunter.premier.net!uunet!in3.uu.net!204.74.114.90!news.genuity.net!news.lafn.org!lafn.org!lafn.org!aw585
  10. From: aw585@lafn.org (Dallas Legan)
  11. Subject: Re: OS/2 Specific DOS and MS-DOS Kermit
  12. X-Nntp-Posting-Host: lafn.org
  13. Message-ID: <1997Feb17.100642.26785@lafn.org>
  14. Sender: news@lafn.org
  15. Reply-To: aw585@lafn.org (Dallas Legan)
  16. Organization: The Los Angeles Free-Net
  17. References: <1997Feb15.090805.155151@forest> <1997Feb14.231518.11060@lafn.org> <E5n8Ho.9rx@echelon.nl>
  18. Date: Mon, 17 Feb 1997 10:06:42 GMT
  19. Lines: 141
  20. Xref: news.columbia.edu comp.protocols.kermit.misc:6604
  21.  
  22.  
  23. (First, I want to thank the people who responded - no definite
  24. answers, yet, but here's my feedback, maybe what I've found can
  25. provide a new clue? - DEL)
  26.  
  27. In a previous article, pcoen@forest.drew.edu (Paul Coen) says:
  28.  
  29. >In article <E5n8Ho.9rx@echelon.nl>, kees@echelon.nl (Kees Hendrikse) writes:
  30. >> In <1997Feb14.231518.11060@lafn.org> aw585@lafn.org (Dallas Legan) writes:
  31. >> 
  32. >>> When booting 'Specific DOS' versions from a bootable DOS disk,
  33. >>> when I boot MS-DOS Kermit, it gives a message:
  34. >>> 
  35. >>> ?Warning: unknown hardware for port. Using Bios as BIOS4.
  36. >>> 
  37. >>> Is there some trick around this problem, or is it
  38. >>> just a limitation of booting DOS from inside OS/2?
  39. >> 
  40. >> Even if you boot a specific DOS from a floppy or a diskimage, you still
  41. >> have to go through OS/2 layers to reach the hardware. Check the settings
  42. >> of the program object and see if COM_DIRECT_ACCESS is enabled. This should
  43. >> give Kermit access to the port you want. If not, try to use the port via
  44. >> the bios: "set port bios 1". 
  45. >> 
  46.  
  47. I tried the COM_DIRECT_ACCESS, but it didn't seem to do the trick.
  48. I'll recheck, to make sure I didn't add any more complications.
  49. Same with set port bios 1 (or rather 'bios 4')
  50.  
  51. >
  52. >Actually, you shouldn't need to do that.  As long as MS-Kermit knows
  53. >what irq & address to look for a com port as, it'll run without
  54. >error messages without COM_DIRECT_ACCESS under OS/2.  I've done
  55. >it on versions from OS/2 2.0 and above.
  56.  
  57. Maybe the IRQ is getting changed?
  58.  
  59. >
  60. >Something else is wrong.  Something else could be using COM4, but
  61. >that's unlikely because he didn't report getting an error message
  62. >in a Presentation Manager window offering recovery choices.
  63. >
  64. >My guess is that Com4 (since there really isn't a standard for it)
  65. >is set to something other than MS-Kermit might expect it to be,
  66. >or else OS/2 can't see it at all due to the same problem (or a hardware
  67. >conflict).
  68. >
  69.  
  70. I read over the KERMIT.BWR MS-DOS Kermit documentation file as 
  71. carefully as possible about use under OS/2. (by the way, it is
  72. version 3.0 if that matters any, with a cheap Zoom modem -
  73. maybe it is one of the hardware brain dead ones contributing to the 
  74. problem.)
  75. I did the examination with DOS DEBUG, and COM4 seemed to be where
  76. it was supposed to be (hex 2e8).
  77.  
  78. >If the COM port works from OS/2 programs (C-Kermit for OS/2 should
  79. >be able to use it if the operating system can see it), you need
  80. >to do a "SET COM4" command (I *think* I'm remembering that
  81. >correctly) and then give the information on where to find Com4.  
  82. >You can get the information from your CONFIG.SYS file, either
  83. >in the line where COM.SYS is loaded, or, if you're using the
  84. >replacement SIO drivers, whatever the name of the device driver
  85. >is -- I'm drawing a blank.  Anyway, write down the irq and 
  86. >base address, and go back to MS-Kermit.
  87.  
  88. I went back and added to
  89. DEVICE=C:\OS2\BOOT\COM.SYS
  90. to make it:
  91. DEVICE=C:\OS2\BOOT\COM.SYS (3,3F8,4) (4,2E8,3)
  92.  
  93. and even added the 
  94. DEVICE=C:\OS2\MDOS\COMDD.SYS
  95. which supposedly some software needs
  96. (I don't know if I put it in the right position, or
  97. even if the location in CONFIG.SYS matters?)
  98.  
  99. and also put in the STARTUP.CMD
  100. a line of
  101. MODE COM4: 57600 N 8 1 RTS=HS OCTS=ON
  102. similar to what was recommended in KERMIT.BWR
  103.  
  104. None of this seemed to help, but maybe I'm overlooking something?
  105.  
  106. >
  107. >Type "set com4 ?" and it'll tell you what the next item it wants
  108. >is -- type it in, insert a space, and hit "?" again.  I can never
  109. >exactly remember the command syntax -- on the rare occasions I've
  110. >had to do this I usually use this method for figuring it out.
  111. >
  112. >If the COM port isn't visible from OS/2, you're going to need
  113. >to look up COM.SYS in the online help and find out the syntax
  114. >for adding port definitions.  And you're going to need to know
  115. >the irq and address for your COM4 (and Com3, for that matter).
  116. >If this is a plug-and-pray device under Warp 4, you can do
  117.                                       AAAAAAAAAA-- no, it's not
  118.                                          it's 3.0
  119.  
  120. >"rmview /irq /io /so" at a command prompt to find out where
  121. >it was actually put by the operating system so you can edit the
  122. >config.sys file.
  123. >
  124. >Again, this error shouldn't be happening if everything is set up
  125. >correctly.  Sorry for the number of "I can't quite remember . . ."
  126.  
  127. (That's OK - not only can I not remember, I never knew to begin with
  128.   ;-)   )
  129.  
  130. >above, but some information is at my office, and not overly
  131. >accessable at the moment.
  132. >
  133.  
  134. This isn't as pressing as it was, because reading over the 
  135. documents more, I found settings to make
  136. MS-DOS Kermit running in a fullscreen DOS VDM session
  137. run a lot perkier then it originally was, and also not to 
  138. hang -
  139. SET TERMINAL TIMESLICE-RELEASE DISABLE
  140. and setting 
  141. HW_TIMER ON
  142. this may not be perfect, but it's a lot better then previously.
  143.  
  144. Still, why not the Specific DOS?
  145. (I like the COMMAND.COM that I'm using on it)
  146. I found that commenting out all COM device drivers
  147. in CONFIG.SYS - COM.SYS AND VCOM.SYS (and COMDD.SYS if that matters
  148. any) enabled MS-DOS Kermit to run from a
  149. Specific DOS session booted from a disk.
  150. This seems extremely awkward, but maybe it provides someone
  151. more knowledgable about OS/2 a clue as to what will work more
  152. smoothly.  Somehow, I suspect maybe the VIO.SYS I've seen
  153. mentioned might solve it, but I don't know.
  154.  
  155. Again, thanks for the consideration,
  156. and sorry for any spelling, grammer, or netiquette violations!
  157.  
  158. Regards,
  159. Dallas E. Legan
  160. 562.862.4854 ext. '*'
  161. legan@acm.org
  162. aw585@lafn.org